\documentclass[a4paper,10pt,titlepage]{article}
\usepackage[paperwidth=180mm,paperheight=285mm,left=1.5cm,top=3cm,right=0.5cm,bottom=1cm,head=2.0cm,includefoot]{geometry}
\usepackage[a4,frame,center,noinfo,horigin=-0.75in]{crop}
\usepackage[utf8]{inputenc}
\usepackage[spanish,activeacute]{babel}
\usepackage{fancyhdr}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{bookman}
\usepackage{amsmath}
\usepackage{color}
\usepackage{longtable}
\usepackage{booktabs}
\usepackage{ulem}
\usepackage[pdfborder={0 0 0 0}]{hyperref}
\usepackage{fixltx2e}
\usepackage{array}
\usepackage{float}
\restylefloat{table}
\usepackage{t1enc}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}
\usepackage{pdfpages} % to import PDF pages
\usepackage{xcolor}
\usepackage{rotating}

\newcommand{\gsubitem}{\subitem{$-$}}

\makeatletter
\makeatother
\title{Archivos Ubicuos - Manual de Proyecto}
\author{Pereira, Fernando Roque\\
	\texttt{91610}\\
	\texttt{fer.pereira9014@gmail.com}
	\and
	Reale, Tomás\\
	\texttt{92255}\\
	\texttt{tomasreale@gmail.com}
	\and
	Zapico, Rodrigo\\
	\texttt{93272}\\
	\texttt{rodri.zapico@gmail.com}}
\date{Junio 2013}

\newpage

\begin{document}
% cuerpo del documento

\pagestyle{fancy}
\lhead{75.42 Taller de Programación I - Veiga \newline Archivos Ubicuos \newline Manual de Proyecto}
\lfoot{Grupo 1}
\rfoot{ P\'agina \thepage \hspace{0.5pt}}
\cfoot{$1^{er}$ Cuatrimestre 2013}
\maketitle
\newpage
\tableofcontents
\newpage

\section{Introducción}
Este proyecto, titulado Archivos Ubicuos, se da en el marco de un trabajo práctico grupal, correspondiente a la asignatura 
Taller de Programación I (75.42), en la cátedra del Ingeniero Andrés Veiga, de la Facultad de Ingeniería de la Universidad de Buenos 
Aires (FIUBA).
Se encomendó la tarea de diseñar y desarrollar un sistema de sincronización de archivos entre diferentes computadoras.

\newpage

\section{Integrantes}
El grupo se conforma de tres integrantes, cada uno con determinadas tareas a realizar detalladas en secciones posteriores.
Estos son: 
\begin{itemize}
 \item Pereira, Fernando Roque
 \item Reale, Tomás
 \item Zapico, Rodrigo
\end{itemize}

\newpage

\section{Descripción}
Archivos Ubicuos es un sistema de sincronización de archivos entre muchas computadoras. Se basa en una estructura 
Cliente-Servidor, en donde una computadora se encarga de tener un repositorio sincronizado general (server) el cual es 
actualizado en base a mensajes que cada cliente le envía. Dentro de la lógica del programa, puede saberse qué versión 
corresponde guardar, y con ella, notificar a los demás clientes o dispositivos que se logueen con el mismo usuario.
Este sistema permite el registro de varios usuarios, como así también seguridad en la información enviada entre una 
computadora y otra.
Por el lado del cliente, el usuario especifica el directorio a sincronizar y puede, mediante la interfaz gráfica del sistema 
operativo utilizado, borrar, crear y modificar archivos en dicho directorio. El cliente se encargará entonces de hacer un 
polling cada cierta cantidad de tiempo (configurable por el usuario) para obtener los cambios realizados y sincronizarlos con 
el repositorio del server. Este aplicación crea y maneja un índice en una carpeta determinada dentro del directorio de 
sincronización, que le permite obtener los datos anteriores y comparar la versión anterior del cliente con la actual.

\newpage

\section{Herramientas utilizadas}
Se enumeran las siguientes herramientas de interés que ayudaron en el desarrollo del proyecto:

\begin{enumerate}
 \item Compilador GNU C++ (g++): Compilador de código escrito en el lenguaje de programación C++, que forma parte de GCC
 \item IDE Eclipse Indigo: Es un entorno de desarrollo integrado que permite la implementación de proyectos en diversos 
 lenguajes. Con los plugin necesarios, soporta lenguajes como C y C++. Se eligió éste IDE debido a su fácil utilización y las 
 comodidades que plantea a la hora de encarar un proyecto de ésta magnitud
 \item IDE Geany: En menor medida, fue utilizado para la implementación del proyecto
 \item Editor de texto Vim: Para cambios menores y rápidos en el código fuente de algún archivo en particular
 \item Depurador GDB: Este depurador pertenece a la familia GNU y se eligió debido a su facilidad a la hora de debugging y 
 la cantidad de herramientas que posee. Se utilizó desde la consola del sistema operativo Ubuntu, utilizado por los tres 
 integrantes del proyecto
 \item Valgrind: Herramienta de profiling muy poderosa que permite corroborar diversas fallas en el sistema, como por 
 ejemplo, leaks de memoria, archivos que no hayan sido cerrados correctamente (incluyendo sockets), lecturas 
 y escrituras inválidas, etc
 \item Subversion: Herramienta utilizada para el control de versiones del proyecto. Permite tener un control completo de 
 todas las modificaciones en el código. Se utilizó desde el plugin para Eclipse, Subclipse
 \item GoogleCode: Como repositorio de código, se utilizó el de Google. Se puede ver el código completo, como así también 
 las diferentes etapas y versiones del mismo en:\\
 https://code.google.com/p/somos-nosotros/
\item www.google.com
\item stackoverflow.com
 
\end{enumerate}


\newpage

\section{División de tareas}

\begin{center}
    \begin{tabular}{| c | c |}
      \hline
      \begin{large}Tarea\end{large} & 
	\begin{large}Integrante/s\end{large}\\
	  \hline
		Diseño e implementación de aplicación cliente & Pereira Fernando\\
	  \hline
		Diseño e implementación de aplicación servidor & Zapico Rodrigo\\
	  \hline
		Diseño e implementación de aplicación monitor y monitor cliente & Reale Tomás\\
	  \hline
		Diseño e implementación del polling local & Pereira Fernando\\
	  \hline
		Delta Encoding & Reale Tomas\\
	  \hline
		Diseño e implementación del sistema de notificaciones & Pereira Fernando\\
		&Zapico Rodrigo\\
	  \hline
	  	Seguridad, HMAC & Reale Tomás\\
	  \hline
	 	Diseño e implementación de la comunicación entre cliente y servidor & Pereira Fernando\\
	 	&Zapico Rodrigo\\
	  \hline
		Creación de makefile para compilación 	& Zapico Rodrigo\\
	  \hline
	\end{tabular}
  \end{center}

\newpage

\section{Evolución}
Siguiendo la recomendación dada por los docentes de la catedra, se intento ir incrementando la funcionalidad del tp
en sucesivas iteraciones.\\
Se decidió desde un principio dejar HMAC y cuestiones de seguridad para el final.\\
La forma de encarar el tp consistió en : división de tareas y responsabilidades,intentando integrar cada 1 semana
( cosa que obviamente no se pudo cumplir a rajatabla, aunque era el ideal ).
Semana a semana se fijaban los objetivos para la semana proxima, que había que hacer, y quien o quienes debian hacerlo.\\
Primero los encargados de la comunicación cliente servidor hicieron un chat. Básicamente, refactorizaron y mejoraron las clases
de sockets implementadas para el tp4 de la misma cátedra. La idea era tener esto totalmente testeado, para , a la hora de tener que debuggear
las funcionalidades propiamente dichas del tp , poder descartar que sea algo de la capa socket.\\
Respecto a la interfaz gráfica, se empezó con una ventana muy simple y un botón, y a medida que se iba adquiriendo conocimiento
sobre gtkmm, se le fue agregando todo lo necesario. En muchas situaciones, el refactorizado consistio en borrar clases enteras,
ya que mientras se avanzaba se iba descubriendo que la libreria gtkmm ya contaba con métodos para solucionar esos problemas específicos.\\
Aunque obviamente se utilizó control de versiones, y se ponía énfasis especial en documentar y comentar lo commiteado, cada aproximadamente
1 semana nos reuniamos ( físicamente,no via internet ) para ir integrando lo que se tenia. \\
Lo primero que estuvo integrado fueron unas mínimas interfaces gráficas con sus respectivas aplicaciones. Esto facilitaba un poco el testeo de las aplicaciones,
ya que es mas facil usar la interfaz grafica a tener que tener que modificar archivos de configuración y luego ejecutar aplicaciones por terminal.\\
Luego la integracón paso a estar dividida en 2 etapas. Una se daba entre cliente y servidor. La otra entre estas aplicaciones y sus respectivas
interfaces graficas.

\newpage

\section{Inconvenientes encontrados}
Uno de los mayores problemas a la hora de encarar el proyecto fue el diseño del sistema de notificaciones. Se comenzó 
pensando un flujo de programa utilizando un solo hilo y un solo puerto del lado del cliente, mediante el cual el server 
enviaría las notificaciones pertinentes a medida que le llegaban desde otros dispositivos, pero llevaba a conflictos y 
un código un tanto desordenado. \bigskip

La idea era mantener una conversación sincrónica entre el cliente y el servidor, es decir, a medida que el cliente enviaba 
las diferencias, el servidor debía responder con la respuesta a dicha diferencia o a dicha consulta. Teniendo un sistema de 
notificaciones como el descrito en el primer párrafo, esto no hubiese sido posible, debido a que quizás, la respuesta a 
determinado mensaje del cliente derivaría en una respuesta de notificación por parte del servidor (en algunos casos).
Descartado esto, se intentó diseñar una solución utilizando un segundo hilo del lado del cliente, que se mantenga escuchando 
constantemente e introduciendo en una cola de mensajes todo lo que llegaba del servidor, tanto notificaciones como respuesta 
a consultas determinadas. Esto también rompía con la conversación sincrónica planteada en cuanto a mensajes de diferencias 
por lo que, si bien podía resultar efectiva, no cabía en nuestro diseño principal del flujo del programa. \bigskip

Por último, se optó la utilización de un segundo puerto, el cual sólo se utilizaría para recibir mensajes de notificación. 
Dichos mensajes, serán guardados en una cola, de donde el cliente en sí, podría sacar y procesar en determinado lugar del 
flujo (en nuestro caso, al comienzo de cada intervalo de polling, se corroboran notificaciones, luego se hace un polling en 
el repositorio local, y se procesan las diferencias en una conversación sincrónica con el server.

\newpage

\section{Análisis de puntos pendientes}
Como primer punto, y, a criterio del grupo de desarrollo, el más importante, queda como punto pendiente hacer al sistema más 
robusto. Ciertos tratados de excepciones obligan al cliente a desconectarse, quizas se hubieran podido tratar de otra forma menos drástica.
Falta el tratar archivos o carpetas con `espacios` en sus nombres.\\
Falta el encriptar claves guardadas.
\newpage

\section{Propuestas de mejora a futuro}
Durante el desarrollo del proyecto se comentaron y hablaron ideas entre los integrantes, las cuales podrían ser de utilidad 
en el sistema, pero que, por falta de tiempo, no se incluyeron en la presentación actual. A saber:
\begin{itemize}
 \item Poder compartir archivos entre distintos usuarios ( una tarea de bastante complejidad )
 \item Un historial de como se fueron modificando los archivos.
\end{itemize}

O sea, las funcionalidades del `dropbox` propiamente dicho.

\newpage

\end{document}